Skip to main content

Application Access

Overview

Some Qarbine features may not be available based on the edition, release level, and other factors.

Access to Qarbine is managed through Principals. Principals include permissions on what tools and what parts of the catalog they can access. As a convenience multiple Principals can belong to an “Access Group'' which defines these permissions. Below is the table listing the initial Qarbine Principals and their usage.

Account Usage Permission Comment
q_computeInitial sign onShould only be used to obtain an API key that is used by other endpoints.
q_adminSign on
q_runnerAccess groupMay only run components.
q_userAccess groupMay read the example folder.May read\write the public folder.Pro Plus tool access.
q_proAccess groupMay read the example folder.May read\write the public folder.Pro tool access.
q_pro_plusAccess groupMay read the example folder.May read\write the public folder.Pro plus tool access.
developerInitial sign onReferences q_user access group which has ProPlus tool access.
guestInitial sign onReferences q_pro access group which has Pro tool access.

Note - A compute node using a bootstrapURL with an account and password must have its associated Qarbine principal defined with the CSV tags containing “computeNode”. This is not required when the apiKey parameter is used.

Managing Principals

Principals are listed in the Principals tab.

  

The first type of a Principal is one that defines all of the permissions inclusively.

  

The second type of a Principal is one where the permissions are defined by an access group.

  

The third type of a Principal is one that acts as an Access Group. Other principals refer to this principal to obtain their permissions.

  

The permissions of a principal can be segmented by

  • active state,
  • tool access,
  • data service access,
  • catalog access,
  • timeframe access and
  • network access.

Defining a Principal

When you define a principal you provide an initial password and whether the user must subsequently change it. This is done in the area shown below.

  

Principals can be used as the basis for programmatic access using API keys. This is done in the area shown below.

  

You can associate generic tags to a principal which are accessible using the signedOnTags() macro function. This list can be used to control template processing.

  

Active State

Principals can easily be activated and deactivated by adjusting the field shown below.

  

If this applies to an access group then many principles may be affected.

Tool Access

Access to tools is set using the drop down shown below.

  

The permission levels are described below.

  

  

Data Service Access

Data services define on what compute node data queries run and their eventual endpoints. The visible data services are set in the list shown below.

  

Elements are removed using the right click pop up menu.

  

Catalog Access

All principals have a private catalog folder. Access to other folders is set in the area shown below.

  

Catalog groups are a convenient way to aggregate many catalog folders into a single object. They are described in a separate document.

Timeframe Access

You can specify that a Principal expires at a point in time using the fields shown below.

  

Network Access

You can restrict access based on IP addresses by setting the Principal property field shown below. The tested IP is the one observed by the Qarbine endpoint service.

  

This is a CSV list of values which are IP addresses and masks commonly referred to as Classless Inter-Domain Routing (CIDR) values. Below is a table of sample CIDR mappings.

CIDR Dotted Quad Mask
/8255.0.0.0
/16255.255.0.0
/24255.255.255.0
/32255.255.255.255

To restrict access to the 192.168.1.x subnet use a CIDR value of 192.168.1.0/24. A useful CIDR calculation tool is available at https://www.subnet-calculator.com/cidr.php